Communication systems such as computer networks, telecommunication systems, and other systems are increasingly using cryptography to encrypt information sent electronically. With the increase in electronic commerce, electronic mail communication, and other information for which users may wish to keep secret, public key cryptography systems employ an encryption key pair, such as a decryption private key and an encryption public key to decrypt and encrypt data. The decryption private keys are secret keys that are protected by the use of encryption techniques and other techniques to help ensure that an attacker cannot readily obtain this critical key. In communications that employ many users, it is not uncommon that a given software application has its own encryption and decryption keys as well as the user of a computer.
Referring to FIG. 1, a trust authority, such as a certification authority in a public key infrastructure, maintains private encryption key history data 10 for one or more subscribers. The certification authority 5 serves as the originating trust authority (trust anchor for the subscriber). The cryptographic engine 12 includes a session key generator 14, a subscriber encryption key pair generator 16, a certification authority signing key pair generator 18, and a remote session key pair generator 20. As known, the key pairs that are generated may all generate from a common key pair generator algorithm if desired. In a public key based system, a subscriber sends a signed request using a private signing key to the originating certification authority 5 requesting a new encryption key pair using a session key generated from the session key generator 14. When transferring the encryption private key from the trust authority to the subscriber, the session key generator is used to create a session key to encrypt the private decryption key. If the subscriber request is password-based, the session key is based on the password which both the subscriber and trust authority know, and is generated independently by the subscriber and the trust authority. If the subscriber request is public key-based, the session key is a random key generated by the trust authority and is transferred to the subscriber encrypted with an existing public key for which the subscriber has the private decryption key in its local storage. The client requests a new encryption certificate and private decryption key. When a key such as a public encryption key expires, the certification authority 5 keeps the history of private encryption keys on a per user basis to allow the user to decrypt old messages. After a client sends the request, the certification authority 5 verifies the signature on the request and generates a new encryption key pair using the subscriber encryption key pair generator 16. The certification authority locally stores the private decryption keys as part of the key history for the subscriber. The certification authority 5 then generates an encryption certificate and sends a new certificate that is signed with the trust authority private signing key generated by the signing key pair generator 18. It encrypts this information using the session public key as known in the art(the private decryption key is encrypted with the session key). As part of the new certificate, a new decryption private key is also sent to the subscriber. The remote session key pair generator 20 generates session key pairs to facilitate secure communication with a subscriber, for example, to send other information to the trusted authority as known in the art.
Conventional public cryptography based security systems may store a user's decryption private key and other user-specific data, such as program settings or user preferences, in secure storage of a server. The storage of such user-specific data in a centralized location accommodates central generation and/or updating of data. This allows updates to be locally accessible to the user from various locations, and may serve as a master copy in case the local data storage or program employing such data is lost or upgraded. Each time a user (subscriber) accesses the server/directory with appropriate identification or access permission, the subscriber obtains access to its user-specific data. A problem with such systems, is that there is typically no history of previous decryption private keys so a subscriber cannot read older encrypted data. For example if a previous e-mail was encrypted using an older encryption key of the subscriber, and the encryption key was subsequently updated or replaced after a period of time, which is common, the e-mail cannot be read using the new decryption private key because it is no longer paired with the older public encryption key.
To overcome this problem, other public key cryptography based security systems store the history of decryption private keys locally in a user's computer memory units and protect this information (for example by encryption) to avoid access by an attacker. In addition, the history of the decryption private keys is stored in a master copy form in the security manager server. In such a system however, such backed-up decryption private keys are only accessible through the manager server and not directly to the user.
Upon loss of a previous decryption private key, which may be 1,024 or 2048 bits long (for example if the RSA algorithm is used), a subscriber or user identified as having the proper access for the community can be allowed to access the stored history data to obtain a previously lost decryption private key. A user may need to recover multiple keys, that is a key history, because the validity of certificates expires periodically, and thus over time users have a number of different key pairs. A new key pair is automatically generated either by the manager server or the user computer upon the expiration of the validity period of the certificates. In order for a user to obtain a copy of the key history from the manager server, the subscriber must prove through special procedures which provide access control, such as a manual telephone call or personal appearance or other mechanism to obtain a new password to gain access to the key history. Because access to the manager server key history is particularly sensitive, such procedures are typically designed to be inappropriate for frequent use, and therefore are inconvenient as a mechanism of regular access to the key history.
Also, a problem arises in moving a public key infrastructure user or other information security user from one originating trust authority (e.g., server) domain to another trust authority domain while preserving the subscriber's ability to decrypt old documents and verify previously signed files. Known systems do not generally provide a system coordinated facility for moving users from one trusted authority, such as a certification authority, to another. Information security systems that maintain decryption key histories or other cryptographic key histories, may have the capability to export decryption keys from a subscriber, such as a software application, network node, stand alone data processing unit or other entity. This may be done, for example, using PKCS #12 Standard protocol which is generally used to transfer private keys and certificates to allow other software applications, for example, in a common node to use private keys. However, such systems typically require the subscriber to export a single decryption key and another software program to import this single key. This becomes disadvantageous because it requires the subscriber to individually manage the process and typically there is no central backup of the users' decryption keys. In addition, the trust anchor or originating certification authority, is typically not changed.
Typically, subscribers are given a system identity and user specific data that is stored at a central server, such as a certification authority. A subscriber may need to be moved from one server to another, for example, if the subscriber changes positions to another part of a company managed by a different certification authority, or for operational load balancing reasons or due to corporate reorganizations, for example. Subscriber data, such as certificate renewal information, key recovery services and other services, should be managed by the destination certification authority to insure proper information security. The destination certification authority that serves as the new certification authority should be able to issue new certificates for the subscriber which reflect the new certification authority security policies. For example, these policies may include the required key length for encryption, the desired encryption algorithm and other information. However, as a subscriber in the new certification authority's domain, the subscriber may be unable to decrypt data encrypted prior to the move if it has lost continued access to its old decryption keys (the decryption key history data). The per user information of the new certification authority does not typically contain information from the user's "previous life" and in particular, the destination server does not typically have the full decryption key history of the subscriber. As such, the subscriber is unable to decrypt older messages encrypted under previous public keys that have since been updated.
Consequently, a need exists for a security information system to provide a more centralized storage of a backup copy of a user's cryptographic key, such as decryption key histories, after a transfer to a different trust authority so that the subscriber's trust anchor changes. A transfer should allow a transfer of a subscriber from one or more trust authorities and if desired, allow a user to move more than once or consolidate cryptographic services from multiple certification authorities to one authority. It would also be advantageous if a combination of a subscriber and certification authority or other entity automated the process to automatically provide a destination certification authority with a backup copy of the user's private decryption key histories.